Python 추상 기본 클래스: 프로토콜 구현 vs. 인터페이스 디자인 마스터하기

소프트웨어 개발의 세계에서 강력하고 유지보수 가능하며 확장 가능한 애플리케이션을 구축하는 것이 궁극적인 목표입니다. 프로젝트가 몇 개의 스크립트에서 국제 팀이 관리하는 복잡한 시스템으로 성장함에 따라 명확한 구조와 예측 가능한 계약의 필요성이 가장 중요해집니다. 서로 다른 시간대에 걸쳐 다른 개발자가 작성했을 수 있는 다양한 구성 요소가 어떻게 원활하고 안정적으로 상호 작용할 수 있도록 할 수 있을까요? 답은 추상화의 원칙에 있습니다.

Python은 동적인 특성을 가지고 있으며, 추상화를 위한 유명한 철학인 "덕 타이핑"을 가지고 있습니다. 객체가 오리처럼 걷고 오리처럼 꽥꽥거린다면, 우리는 그것을 오리로 대합니다. 이러한 유연성은 Python의 가장 큰 강점 중 하나로, 빠른 개발과 깔끔하고 읽기 쉬운 코드를 촉진합니다. 그러나 대규모 애플리케이션에서는 암묵적인 계약에만 의존하면 미묘한 버그와 유지보수 문제가 발생할 수 있습니다. "오리"가 예상치 못하게 날지 못하면 어떻게 될까요? 이때 Python의 추상 기본 클래스(ABC)가 등장하여 Python의 동적인 정신을 희생하지 않고도 공식 계약을 생성하는 강력한 메커니즘을 제공합니다.

하지만 여기서 중요하고 종종 오해되는 구분이 있습니다. Python의 ABC는 만능 도구가 아닙니다. 이들은 소프트웨어 디자인의 두 가지 뚜렷하고 강력한 철학을 제공합니다. 즉, 상속을 요구하는 명시적이고 공식적인 인터페이스를 생성하고, 기능을 확인하는 유연한 프로토콜을 정의하는 것입니다. 이 두 가지 접근 방식, 즉 인터페이스 디자인과 프로토콜 구현의 차이를 이해하는 것이 Python에서 객체 지향 디자인의 잠재력을 최대한 발휘하고 유연하고 안전한 코드를 작성하는 열쇠입니다. 이 가이드에서는 두 가지 철학을 탐구하고, 글로벌 소프트웨어 프로젝트에서 각 접근 방식을 사용할 때에 대한 실용적인 예제와 명확한 지침을 제공합니다.

형식에 대한 참고 사항: 특정 형식 제약 조건을 준수하기 위해 이 기사의 코드 예제는 일반 텍스트 태그 내에서 볼드체 및 이탤릭체 스타일을 사용하여 제공됩니다. 가독성을 위해 편집기에 복사하여 붙여넣는 것을 권장합니다.

기반: 추상 기본 클래스란 정확히 무엇인가?

두 가지 디자인 철학을 자세히 살펴보기 전에 견고한 기반을 구축해 봅시다. 추상 기본 클래스란 무엇인가요? 기본적으로 ABC는 다른 클래스를 위한 청사진입니다. 이는 준수하는 모든 하위 클래스가 구현해야 하는 메서드 및 속성 집합을 정의합니다. "이 가족의 일부라고 주장하는 모든 클래스는 이러한 특정 기능을 가져야 한다"고 말하는 방법입니다.

Python의 내장 `abc` 모듈은 ABC를 생성하는 도구를 제공합니다. 두 가지 주요 구성 요소는 다음과 같습니다.

• `ABC`: ABC를 생성하기 위한 메타클래스로 사용되는 도우미 클래스입니다. 최신 Python(3.4+)에서는 단순히 abc.ABC를 상속하면 됩니다.
• `@abstractmethod`: 메서드를 추상으로 표시하는 데 사용되는 데코레이터입니다. ABC의 모든 하위 클래스는 이러한 메서드를 구현해야 합니다.

ABC를 제어하는 두 가지 기본 규칙이 있습니다.

1. 구현되지 않은 추상 메서드가 있는 ABC의 인스턴스를 생성할 수 없습니다. 이는 템플릿이며 완성된 제품이 아닙니다.
2. 모든 구체적인 하위 클래스는 상속된 모든 추상 메서드를 구현해야 합니다. 그렇게 하지 못하면 해당 클래스도 추상 클래스가 되며 인스턴스를 생성할 수 없습니다.

고전적인 예제인 미디어 파일 처리 시스템을 통해 이를 확인해 봅시다.

예제: 간단한 MediaFile ABC

다양한 유형의 미디어를 처리해야 하는 애플리케이션을 구축한다고 가정해 봅시다. 모든 미디어 파일은 형식에 관계없이 재생 가능해야 하며 메타데이터가 있어야 합니다. ABC로 이 계약을 정의할 수 있습니다.

import abc

class MediaFile(abc.ABC):
    def __init__(self, filepath: str):
        self.filepath = filepath
        print(f"Base init for {self.filepath}")
    @abc.abstractmethod
    def play(self) -> None:
        """Play the media file."""
        raise NotImplementedError
    @abc.abstractmethod
    def get_metadata(self) -> dict:
        """Return a dictionary of media metadata."""
        raise NotImplementedError

MediaFile의 인스턴스를 직접 생성하려고 하면 Python에서 중지됩니다.

# TypeError가 발생합니다
# media = MediaFile("path/to/somefile.txt")
# TypeError: Can't instantiate abstract class MediaFile with abstract methods get_metadata, play

이 청사진을 사용하려면 play() 및 get_metadata()에 대한 구현을 제공하는 구체적인 하위 클래스를 만들어야 합니다.

class AudioFile(MediaFile):
    def play(self) -> None:
        print(f"Playing audio from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "mp3", "duration_seconds": 180}
class VideoFile(MediaFile):
    def play(self) -> None:
        print(f"Playing video from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "h264", "resolution": "1920x1080"}

이제 MediaFile에 의해 정의된 계약을 충족하므로 AudioFile 및 VideoFile의 인스턴스를 생성할 수 있습니다. 이것이 ABC의 기본 메커니즘입니다. 그러나 진정한 힘은 이 메커니즘을 *사용하는 방법*에서 나옵니다.

첫 번째 철학: 형식 인터페이스 디자인으로서의 ABC (명목 타이핑)

ABC를 사용하는 첫 번째이자 가장 전통적인 방법은 형식 인터페이스 디자인입니다. 이 접근 방식은 Java, C++, C#와 같은 언어의 개발자에게 익숙한 명목 타이핑이라는 개념에 뿌리를 두고 있습니다. 명목 시스템에서 유형의 호환성은 이름과 명시적 선언에 의해 결정됩니다. 이 맥락에서 클래스는 MediaFile ABC를 명시적으로 상속하는 경우에만 MediaFile로 간주됩니다.

전문가 인증과 같다고 생각하십시오. 공인 프로젝트 관리자가 되려면 단순히 그렇게 행동하는 것만으로는 충분하지 않습니다. 특정 시험에 합격하고 자격이 있음을 명시적으로 명시하는 공식 인증서를 받아야 합니다. 인증의 이름과 계보는 중요합니다.

이 모델에서 ABC는 협상 불가능한 계약 역할을 합니다. 이를 상속함으로써 클래스는 필요한 기능을 제공하겠다는 공식적인 약속을 시스템의 나머지 부분에 합니다.

예제: 데이터 내보내기 프레임워크

다양한 형식으로 데이터를 내보낼 수 있는 프레임워크를 구축한다고 가정해 봅시다. 모든 내보내기 플러그인이 엄격한 구조를 준수하도록 하려면 DataExporter 인터페이스를 정의할 수 있습니다.

import abc
from datetime import datetime
class DataExporter(abc.ABC):
    """A formal interface for data exporting classes."""
    @abc.abstractmethod
    def export(self, data: list[dict]) -> str:
        """Exports data and returns a status message."""
        pass
    def get_timestamp(self) -> str:
        """A concrete helper method shared by all subclasses."""
        return datetime.utcnow().isoformat()
class CSVExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.csv"
        print(f"Exporting {len(data)} rows to {filename}")
        # ... actual CSV writing logic ...
        return f"Successfully exported to {filename}"
class JSONExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.json"
        print(f"Exporting {len(data)} records to {filename}")
        # ... actual JSON writing logic ...
        return f"Successfully exported to {filename}"

여기서 CSVExporter와 JSONExporter는 명시적으로 그리고 검증 가능하게 DataExporter입니다. 애플리케이션의 핵심 로직은 이 계약에 안전하게 의존할 수 있습니다.

def run_export_process(exporter: DataExporter, data_to_export: list[dict]):
    print("--- Starting export process ---")
    if not isinstance(exporter, DataExporter):
        raise TypeError("Exporter must be a valid DataExporter implementation.")
    status = exporter.export(data_to_export)
    print(f"Process finished with status: {status}")
# Usage
data = [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
run_export_process(CSVExporter(), data)
run_export_process(JSONExporter(), data)

ABC는 또한 get_timestamp()라는 구체적인 메서드를 제공하며, 이는 모든 하위 클래스에 공유 기능을 제공합니다. 이것은 인터페이스 기반 디자인에서 흔하고 강력한 패턴입니다.

형식 인터페이스 접근 방식의 장단점

장점:

• 명확하고 명시적: 계약이 매우 명확합니다. 개발자는 상속 라인 class CSVExporter(DataExporter):를 보고 클래스의 역할과 기능을 즉시 이해할 수 있습니다.
• 도구 친화적: IDE, 린터 및 정적 분석 도구는 계약을 쉽게 확인할 수 있어 훌륭한 자동 완성 및 오류 검사를 제공합니다.
• 공유 기능: ABC는 구체적인 메서드를 제공하여 실제 기본 클래스 역할을 하고 코드 중복을 줄일 수 있습니다.
• 친숙함: 이 패턴은 대부분의 다른 객체 지향 언어의 개발자에게 즉시 인식됩니다.

단점:

• 강한 결합: 구체적인 클래스는 이제 ABC와 직접적으로 연결됩니다. ABC를 이동하거나 변경해야 하는 경우 모든 하위 클래스에 영향을 미칩니다.
• 견고성 부족: 엄격한 계층적 관계를 강제합니다. 논리적으로 내보내기 역할을 할 수 있지만 이미 다른 필수 기본 클래스를 상속하는 클래스가 있다면 어떻게 될까요? Python의 다중 상속은 이 문제를 해결할 수 있지만 자체적인 복잡성(예: 다이아몬드 문제)을 초래할 수도 있습니다.
• 침습성: 타사 코드를 적용하는 데 사용할 수 없습니다. export() 메서드가 있는 클래스를 제공하는 라이브러리를 사용하는 경우, (불가능하거나 바람직하지 않을 수 있는) 해당 클래스를 상속하지 않고서는 DataExporter로 만들 수 없습니다.

두 번째 철학: 프로토콜 구현으로서의 ABC (구조적 타이핑)

두 번째, 더 "Pythonic"한 철학은 덕 타이핑과 일치합니다. 이 접근 방식은 구조적 타이핑을 사용하며, 여기서 호환성은 이름이나 계보가 아니라 구조와 동작에 의해 결정됩니다. 객체가 작업을 수행하는 데 필요한 메서드와 속성을 가지고 있다면, 선언된 클래스 계층 구조에 관계없이 해당 작업에 적합한 유형으로 간주됩니다.

수영할 수 있는 능력을 생각해 보세요. 수영선수로 간주되기 위해 인증서가 필요하거나 "수영선수" 계보에 속할 필요는 없습니다. 물에 익사하지 않고 스스로 추진할 수 있다면 구조적으로 수영선수입니다. 사람, 개, 오리 모두 수영선수가 될 수 있습니다.

ABC는 이 개념을 형식화하는 데 사용될 수 있습니다. 상속을 강제하는 대신, 다른 클래스를 해당 클래스의 가상 하위 클래스로 인식하는 ABC를 정의할 수 있으며, 이는 필수 프로토콜을 구현하는 경우에만 가능합니다. 이는 특수 마법 메서드인 __subclasshook__을 통해 달성됩니다.

isinstance(obj, MyABC) 또는 issubclass(SomeClass, MyABC)를 호출할 때 Python은 먼저 명시적 상속을 확인합니다. 실패하면 MyABC에 __subclasshook__ 메서드가 있는지 확인합니다. 그렇다면 Python은 이를 호출하여 "이 클래스를 귀하의 하위 클래스로 간주합니까?"라고 묻습니다. 이를 통해 ABC는 구조를 기반으로 멤버십 기준을 정의할 수 있습니다.

예제: Serializable 프로토콜

딕셔너리로 직렬화될 수 있는 객체에 대한 프로토콜을 정의해 봅시다. 시스템의 모든 직렬화 가능한 객체가 공통 기본 클래스를 상속하도록 강제하고 싶지는 않습니다. 해당 객체는 데이터베이스 모델, 데이터 전송 객체 또는 간단한 컨테이너일 수 있습니다.

import abc
class Serializable(abc.ABC):
    @abc.abstractmethod
    def to_dict(self) -> dict:
        pass
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Serializable:
            # 'to_dict'가 C의 메서드 해석 순서에 있는지 확인
            if any("to_dict" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

이제 몇 가지 클래스를 만들어 봅시다. 중요한 것은 이들 중 어느 것도 Serializable을 상속하지 않는다는 것입니다.

class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    def to_dict(self) -> dict:
        return {"name": self.name, "email": self.email}
class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    # 이 클래스는 프로토콜을 준수하지 않습니다.
class Configuration:
    def __init__(self, setting: str):
        self.setting = setting

프로토콜에 대해 확인해 봅시다.

print(f"Is User serializable? {isinstance(User('Test', 't@t.com'), Serializable)}")
print(f"Is Product serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
print(f"Is Configuration serializable? {isinstance(Configuration('ON'), Serializable)}")
# 출력:
# Is User serializable? True
# Is Product serializable? False <- 왜 그럴까요? 수정해 봅시다.
# Is Configuration serializable? False

아, 흥미로운 버그입니다! Product 클래스에는 to_dict 메서드가 없습니다. 추가해 봅시다.

class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    def to_dict(self) -> dict: # 메서드 추가
        return {"sku": self.sku, "price": self.price}
print(f"Is Product now serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
# 출력:
# Is Product now serializable? True

User와 Product는 공통 부모 클래스(object 외)를 공유하지 않더라도, 이 둘 모두 Serializable로 취급될 수 있습니다. 왜냐하면 이들이 프로토콜을 충족하기 때문입니다. 이는 매우 강력한 디커플링 도구입니다.

프로토콜 접근 방식의 장단점

장점:

• 최대 유연성: 매우 느슨한 결합을 촉진합니다. 구성 요소는 구현 계보가 아닌 동작에만 신경 씁니다.
• 적응성: 기존 코드를 수정하지 않고 시스템의 인터페이스에 맞추기 위해, 특히 타사 라이브러리의 코드를 적응시키는 데 완벽합니다.
• 구성 촉진: 깊고 견고한 상속 트리보다는 독립적인 기능으로 구축된 개체로 구성하는 스타일을 장려합니다.

단점:

• 암묵적 계약: 클래스와 해당 클래스가 구현하는 프로토콜 간의 관계는 클래스 정의에서 즉시 명확하지 않습니다. 개발자는 User 객체가 Serializable로 취급되는 이유를 이해하기 위해 코드베이스를 검색해야 할 수 있습니다.
• 런타임 오버헤드: isinstance 검사는 __subclasshook__을 호출하고 클래스의 메서드에 대한 검사를 수행해야 하므로 더 느릴 수 있습니다.
• 복잡성 가능성: __subclasshook__ 내부의 로직은 프로토콜이 여러 메서드, 인수 또는 반환 유형을 포함하는 경우 매우 복잡해질 수 있습니다.

현대적 종합: typing.Protocol 및 정적 분석

Python이 대규모 시스템에서 사용되는 것이 증가함에 따라 더 나은 정적 분석에 대한 열망도 커졌습니다. __subclasshook__ 접근 방식은 강력하지만 순전히 런타임 메커니즘입니다. 코드를 실행하기도 전에 구조적 타이핑의 이점을 얻을 수 있다면 어떨까요?

이것이 PEP 544에서 `typing.Protocol`이 도입된 이유입니다. 이는 주로 Mypy, Pyright 또는 PyCharm의 검사기 등 정적 타입 검사를 위한 프로토콜을 정의하는 표준화되고 우아한 방법을 제공합니다.

Protocol 클래스는 __subclasshook__ 예제와 유사하게 작동하지만 상용구 코드가 없습니다. 단순히 메서드와 해당 시그니처를 정의하면 됩니다. 일치하는 메서드와 시그니처를 가진 모든 클래스는 정적 타입 검사기에 의해 구조적으로 호환되는 것으로 간주됩니다.

예제: Quacker 프로토콜

현대적 도구를 사용하여 고전적인 덕 타이핑 예제를 다시 살펴봅시다.

from typing import Protocol
class Quacker(Protocol):
    def quack(self, volume: int) -> str:
        """Produces a quacking sound."""
        ... # 참고: 프로토콜 메서드의 본문은 필요하지 않습니다.
class Duck:
    def quack(self, volume: int) -> str:
        return f"QUACK! (at volume {volume})"
class Dog:
    def bark(self, volume: int) -> str:
        return f"WOOF! (at volume {volume})"
def make_sound(animal: Quacker):
    print(animal.quack(10))
make_sound(Duck()) # 정적 분석 통과
make_sound(Dog()) # 정적 분석 실패!

이 코드를 Mypy와 같은 타입 검사기로 실행하면 `make_sound(Dog())` 줄에 오류가 발생합니다. Argument 1 to "make_sound" has incompatible type "Dog"; expected "Quacker". 타입 검사기는 Dog에 quack 메서드가 없기 때문에 Quacker 프로토콜을 충족하지 못한다는 것을 이해합니다. 이것은 코드가 실행되기 전에 오류를 포착합니다.

`@runtime_checkable`을 사용한 런타임 프로토콜

기본적으로 typing.Protocol은 정적 분석만을 위한 것입니다. 런타임 isinstance 검사에 사용하려고 하면 오류가 발생합니다.

# isinstance(Duck(), Quacker) # -> TypeError: Protocol 'Quacker' cannot be instantiated

그러나 `@runtime_checkable` 데코레이터를 사용하여 정적 분석과 런타임 동작 간의 격차를 해소할 수 있습니다. 이는 실제로 Python에게 자동으로 __subclasshook__ 로직을 생성하도록 지시하는 것과 같습니다.

from typing import Protocol, runtime_checkable
@runtime_checkable
class Quacker(Protocol):
    def quack(self, volume: int) -> str: ...
class Duck:
    def quack(self, volume: int) -> str: return "..."
print(f"Is Duck an instance of Quacker? {isinstance(Duck(), Quacker)}")
# 출력:
# Is Duck an instance of Quacker? True

이를 통해 두 가지 장점을 모두 얻을 수 있습니다. 정적 분석을 위한 깔끔하고 선언적인 프로토콜 정의와 필요할 때 런타임 유효성 검사 옵션. 그러나 프로토콜에 대한 런타임 검사는 표준 isinstance 호출보다 느리다는 점에 유의해야 하므로 신중하게 사용해야 합니다.

실용적인 의사 결정: 글로벌 개발자를 위한 가이드

그렇다면 어떤 접근 방식을 선택해야 할까요? 답은 전적으로 특정 사용 사례에 달려 있습니다. 다음은 국제 소프트웨어 프로젝트의 일반적인 시나리오를 기반으로 한 실용적인 가이드입니다.

시나리오 1: 글로벌 SaaS 제품을 위한 플러그인 아키텍처 구축

전 세계의 1차 및 3차 개발자가 확장할 시스템(예: 전자 상거래 플랫폼, CMS)을 설계하고 있습니다. 이러한 플러그인은 핵심 애플리케이션과 깊이 통합되어야 합니다.

• 권장 사항: 형식 인터페이스 (명목 `abc.ABC`).
• 이유: 명확성, 안정성 및 명시성이 가장 중요합니다. 전 세계 플러그인 개발자가 BasePlugin ABC를 상속하도록 의도적으로 선택해야 하는 비협상 계약이 필요합니다. 이렇게 하면 API가 모호해지지 않습니다. 또한 기본 클래스에 필수적인 도우미 메서드(예: 로깅, 구성 액세스, 국제화)를 제공할 수 있으며, 이는 개발자 생태계에 큰 이점입니다.

시나리오 2: 여러 관련 없는 API의 금융 데이터 처리

귀사의 핀테크 애플리케이션은 Stripe, PayPal, Adyen 및 라틴 아메리카의 Mercado Pago와 같은 지역 제공업체와 같은 다양한 글로벌 결제 게이트웨이에서 거래 데이터를 소비해야 합니다. 해당 SDK에서 반환되는 객체는 완전히 귀하의 통제 밖에 있습니다.

• 권장 사항: 프로토콜 (`typing.Protocol`).
• 이유: 이러한 타사 SDK의 소스 코드를 수정하여 Transaction 기본 클래스를 상속하도록 만들 수 없습니다. 그러나 해당 거래 객체가 get_id(), get_amount(), get_currency()와 같은 메서드를 가지고 있다는 것을 알고 있습니다. TransactionProtocol과 함께 어댑터 패턴을 사용하여 통일된 보기를 만들 수 있습니다. 프로토콜을 사용하면 필요한 데이터의 *모양*을 정의할 수 있으므로, 프로토콜에 맞게 조정할 수만 있다면 어떤 데이터 소스와도 작동하는 처리 로직을 작성할 수 있습니다.

시나리오 3: 대규모, 모놀리식 레거시 애플리케이션 리팩토링

레거시 모놀리스를 최신 마이크로 서비스로 분해하는 작업을 맡았습니다. 기존 코드베이스는 종속성의 복잡한 웹이며, 모든 것을 한 번에 다시 작성하지 않고 명확한 경계를 도입해야 합니다.

• 권장 사항: 혼합, 그러나 프로토콜에 크게 의존.
• 이유: 프로토콜은 점진적 리팩토링에 탁월한 도구입니다. 먼저 typing.Protocol을 사용하여 새 서비스 간의 이상적인 인터페이스를 정의할 수 있습니다. 그런 다음 기존 핵심 코드를 즉시 변경하지 않고 이러한 프로토콜을 준수하도록 모놀리스의 일부에 대한 어댑터를 작성할 수 있습니다. 이렇게 하면 구성 요소를 점진적으로 디커플링할 수 있습니다. 구성 요소가 완전히 디커플링되고 프로토콜을 통해서만 통신하면 자체 서비스로 추출할 준비가 된 것입니다. 형식 ABC는 나중에 새로운 깔끔한 서비스 내의 핵심 모델을 정의하는 데 사용될 수 있습니다.

결론: 추상화를 코드로 엮기

Python의 추상 기본 클래스는 Python의 실용적인 디자인에 대한 증거입니다. 이는 전통적인 객체 지향 프로그래밍의 구조화된 규율과 덕 타이핑의 동적 유연성을 모두 존중하는 정교한 추상화 도구 세트를 제공합니다.

암묵적 계약에서 형식 계약으로의 여정은 코드베이스가 성숙했음을 나타내는 신호입니다. ABC의 두 가지 철학을 이해함으로써 더 깔끔하고 유지보수 가능하며 확장 가능한 애플리케이션으로 이어지는 정보에 입각한 아키텍처 결정을 내릴 수 있습니다.

주요 내용을 요약하자면 다음과 같습니다.

• 형식 인터페이스 디자인 (명목 타이핑): 명시적이고 모호하지 않으며 검색 가능한 계약이 필요한 경우 직접 상속과 함께 abc.ABC를 사용합니다. 이는 프레임워크, 플러그인 시스템 및 클래스 계층 구조를 제어하는 상황에 이상적입니다. 선언에 의해 클래스가 무엇인지에 관한 것입니다.
• 프로토콜 구현 (구조적 타이핑): 유연성, 디커플링 및 기존 코드를 적응시키는 기능이 필요한 경우 typing.Protocol을 사용합니다. 타사 라이브러리 작업, 레거시 시스템 리팩토링 및 동작 다형성을 위한 설계에 완벽합니다. 클래스가 무엇을 할 수 있는지의 구조에 관한 것입니다.

인터페이스와 프로토콜 간의 선택은 단순한 기술 세부 사항이 아닙니다. 소프트웨어의 진화 방식을 형성할 근본적인 설계 결정입니다. 둘 다 숙달함으로써 Python 코드를 강력하고 효율적일 뿐만 아니라 우아하고 변화에 대한 복원력 있게 작성할 수 있습니다.